DAY16 淺談 HTTP 協定版本：從 0.9 到 3 的進化之路（二）

2024 iThome 鐵人賽

DAY 16

Software Development

從零開始的後端學習之旅系列第 16 篇

16th鐵人賽 quic http/1.1 http/2 http/3

Lin

團隊好想工作室 v8.0

2024-09-30 16:52:43

292 瀏覽

分享至

前言

接續昨天的協定版本介紹，今天要來介紹的是：HTTP/1.1、HTTP/2 以及 HTTP/3 ，那事不宜遲，就趕快來進入正題吧，GoGo!

HTTP/1.1

RFC 2068作為 HTTP/1.1 的正式規範在1997年初被發布，距離 HTTP/1.0 的發佈僅僅過了幾個月，不過 RFC 2068 已經過時，本篇文章會以RFC 9112的內容為主，那就來看看在這個版本改變了什麼：

Host header 的引入：以下是官方文件的介紹

The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL).
The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.

Host 標頭的值必須代表原始 URL 中的主機名稱，當伺服器有很多個網站共用一個 IP 位址時，伺服器必須透過使用者傳送的 request header 中的 Host 去辨別使用者想要前往的是哪個網站。在這個版本中 Host 這個標頭是強制要求的，目的是讓伺服器能夠知道所請求的主機名稱，避免出現錯誤，範例如下：
```
    GET /pub/WWW/ HTTP/1.1
    Host: www.w3.org
```
要前往的就是http://www.w3.org/pub/WWW/這個網站
```
    GET /pub/WWW/ HTTP/1.1
    Host: www.w3.com
```
要前往的則是http://www.w3.com/pub/WWW/這個網站
Chunked Transfer Coding（分塊傳輸代碼）：可以將未知大小的資料透過分塊進行傳輸，並且持續性地在同個連接中持續傳送，不需要多次重新建立連接，保持了連接的持久性。
使用持久連線（persistent connections）：以下是官方文件的敘述

HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection. HTTP implementations SHOULD support persistent connections.

之前協定版本在每次請求發送後收到回應就會斷開連線，不同的是 HTTP/1.1 允許在同一個連線中發送多次請求以及回應，解決了多次重複建立連接的效能浪費以及延遲問題。而為了保持連線持久性，每個請求或回應都必須明確定義其長度，也就是說不是透過關閉連接來定義訊息長度，可以利用 Content-Length 來指定訊息長度，以避免新的請求與未完成的請求混亂。
pipelining 的使用：如以下範例，使用者可以一次發出多個請求
```
     GET /page1 HTTP/1.1
     GET /page2 HTTP/1.1
     GET /page3 HTTP/1.1
```
如果這些請求都是安全方法，伺服器可以並行處理多個請求，而不需要等到第一個請求收到回應後才發出後續請求，不過伺服器在回應時還是要照著請求的順序依序回應。
新增了 PUT、DELETE、OPTIONS、TRACE、CONNECT 等請求方法。

更高效能的 HTTP/2

RFC 7540 作為 HTTP/2 的正式規範在 2015 年被發布，而這個規範已經過時，因此會以RFC 9113作為參考資料：

HTTP/2 中的基本協定單元是幀（frame），每種幀的類型都有不同的用途。例如 header frame 跟 data frame 就是 HTTP 請求和回應的基礎。
標頭的壓縮與解壓縮（header compression and decompression）：在傳輸數據時將標頭進行壓縮以降低傳輸的數據量，並提升傳輸的效率。
Streams and Multiplexing：雖然在HTTP/1.1就可以在同一個連接中發出多個請求，但會依照先進來先處理的順序，只要前面的請求被阻塞時，後面的請求也會跟著塞住，出現隊頭阻塞（Head-of-line blocking）的問題。而 HTTP/2 連線可以包含多個並發開啟的流，伺服器可以同時處理這些請求，避免阻塞的狀況發生。

基於 QUIC 的 HTTP 協定：HTTP/3

RFC 9114 作為 HTTP/3 的正式規範在 2022 年被發布，與之前協定版本不同的是，HTTP/3 使用的是基於 UDP 協定的傳輸協定：QUIC

降低延遲：QUIC 不是基於 TCP 協定，建立連接前不需經過三次握手，顯著減少連接建立所需的時間。
將加密整合在握手過程，以下為官方文件敘述：

QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol. HTTP/3 clients MUST support a mechanism to indicate the target host to the server during the TLS handshake.

HTTP/3 可以在建立連接的同時進行加密和身份驗證，並且使用者端要在握手過程中提供伺服器的域名，使得伺服器能夠正確識別並處理請求，提高了安全性以及傳輸的效率。
對於每個 stream 都有獨立的流量控制，因此當有封包遺失時，有內建機制進行重傳，但受到影響的只有那個 stream ，其他的 stream 並不會受到影響，不會出現多路復用的情況
連線遷移（Connection Migration ）：在網路變更時（wifi 切換成行動網路）保持連接，以下為官方文件敘述：

The use of a connection ID allows connections to survive changes to endpoint addresses (IP address and port), such as those caused by an endpoint migrating to a new network.

與 TCP 協定透過 IP 位址來識別連線不同，只要切換網路時就要重新進行連線。而 QUIC 在連接的開始會為每個連線分配一個編號（connection ID），透過編號來識別連線，因此只要持續使用相同的編號，原本的連線依舊可以繼續使用，從行動網路切換成wifi（改變 IP 位址）也不需要再經歷斷開連線/重新連線的時間延遲。